1. Field of Invention
Embodiments of invention relate generally to the software arts, and, more specifically, to a Web services (WS) reliable messaging application programming interface (API) to incorporate reliable messaging in a Web services client application.
2. Background
The term “Web services” is understood to mean a standards-based, service oriented architecture (SOA) than can be used to engage in business relationships (e.g., buying and selling) in a partially or wholly automated fashion over a public network such as the Internet (“the Web”). Standards bodies and interoperability organizations that have contributed to the Web services effort include the World Wide Web Consortium (W3C), the Organization for the Advancement of Structured Information Standards (OASIS), the Internet Engineering Task Force (IETF) and the Web Services Interoperability Organization (WS-I).
Web services are services (usually including some combination of programming and data, but possibly including human resources as well) that are made available from a business's Web server for Web users or other Web-connected programs. Providers of Web services are generally known as application service providers. Web services range from such major services as storage management and customer relationship management (CRM) down to much more limited services such as the furnishing of a stock quote and the checking of bids for an auction item. The accelerating creation and availability of these services is a major Web trend.
Users can access some Web services through a peer-to-peer arrangement rather than by going to a central server. Some services can communicate with other services and this exchange of procedures and data is generally enabled by a class of software known as middleware. Services previously possible only with the older standardized service known as Electronic Data Interchange (EDI) increasingly are likely to become Web services. Besides the standardization and wide availability to users and businesses of the Internet itself, Web services are also increasingly enabled by the use of the Extensible Markup Language (XML) as a means of standardizing data formats and exchanging data. XML is the foundation for the Web Services Description Language (WSDL).
As Web services proliferate, concerns include the overall demands on network bandwidth and, for any particular service, the effect on performance as demands for that service rise. A number of new products have emerged that enable software developers to create or modify existing applications that can be “published” (made known and potentially accessible) as Web services.
With Web services, the world is divided into providers and consumers. The Web service provider develops a Web service in a certain programming language and deploys it to its own server runtime environment. The service is described in the Web Services Description Language (WSDL) using special XML tags. The service description is published in a common service directory. Web services directories are generally organized following the UDDI specification. Major software vendors such as SAP, Microsoft, and IBM operate their own public UDDI directories. A developer on the Web service consumer (client) side can browse the UDDI directory and look for applicable services. The consumer may then download the WSDL of a selected Web service and trigger the execution of the Web service over the communication link that is established between the consumer and the provider. Web service invocations are standardized using SOAP, while a SOAP request contains the name of the Web service plus its actual parameters. A SOAP response contains the result parameters based on the signature that is exposed in the WSDL. Note that in a Web service scenario, the use of the directory is optional; if you know where a Web service runs and you obtain the description directly from the Web service provider, you can invoke the Web service without using the directory.
Consuming services essentially involves some client application that is interested in invoking the functionality exposed by the service. Services may be consumed by some other Service implementation, or by a composite application that invokes a series of services or even directly from a User Interface. In the Web services world, it does not matter where the Service is invoked from. The wire format of the Service messages, the Service behavior, and so on, are not specific to the environment from which the Service is invoked.
Sun's JAX-RPC specification supports a client programming model where the client can be programmed directly against the Service interface. The client is provided with Service proxy objects that support the exactly same interface as the actual Service. The proxy object encapsulates many gory details related to data binding, network address of the Service, transport protocol handling, etc, and gives an illusion of the Service being local to the client.
The proxy objects in J2SE applications are like any other Java objects. However in the case of J2EE, which is a managed environment, proxy objects can be administered and made accessible to client applications via Java Naming and Directory Interface (JNDI). The Web services for J2EE (JSR 109) specification defines clearly the programming, packaging and deployment model for clients in a J2EE environment.
Behind the scenes, the proxy object must deal with the wire level messages that map to the Java data structures. In some situations, even the client program itself needs to directly manipulate the message. Web services use SOAP as the neutral wire format for Service messages. In the Java world, SOAP with Attachments API for Java (SAAJ) provides a Java object model for different parts of SOAP messages, and an API for accessing the same.
As the core Web services specifications (WSDL, SOAP and UDDI) are maturing and being adopted, new Web services specifications are emerging to fulfill the enterprise application and quality of service requirements, for example: Web services Security, Web service Business Process Execution Language, Web service Policy, and Web services Notification. Corresponding technologies in Java are expected to follow suit. An example of such an effort is JSR 208, which aims at standardizing a Java-based plug and play framework where components from different vendors that offer business integration functionality via Web services can coexist.